배포가 Alloy 프로비저닝을 포함하도록 - #39

Situation

• 이 박스의 Alloy 설정이 배포와 무관하게 옛 상태로 남고 있었다. provision-observability.sh 는 필요한 일(infra 공용 블록 fetch → SSM 자격 로드 → 자기 박스 값으로 호출)을 이미 전부 하지만, 배포 워크플로가 그것을 호출하지 않아 사람이 박스에서 수동 실행할 때만 반영됐다.
• 드러난 계기: 메트릭 카디널리티 누수 차단과 수집 주기 60s 조정 infra#44 로 Alloy config 를 감축(수집 주기 60s · 카디널리티 누수 차단 · collector 41→12)한 뒤, 이 박스를 재배포해도 아무 변화가 없었다.

core 만 배포에 프로비저닝 단계가 있어 생긴 비대칭이고, 그 결과 공용 config 를 고쳐도 5개 박스 중 2개(core dev·prod)에만 퍼졌다.

Task

• 공용 config 변경이 이 박스에도 자동으로 반영되게 한다. 수동 실행에 기대지 않는다.

Action

deploy.yml 에 기존 스크립트를 실행하는 단계를 추가했다.

• Upload blocks 의 source 에 provision-observability.sh 를 더해 박스로 올린다.
• 앱 배포 앞에 실행한다 — core 와 같은 순서(provision → deploy)이고, 관측이 깨진 채 앱만 새로 올라가는 상태를 막는다.
• 스크립트가 자기 완결적이라(공용 블록을 raw.githubusercontent 에서 직접 fetch, 자격은 박스가 SSM 공유 경로에서 직접 조회) 러너가 넘길 인자나 secret 이 없다.

검토했으나 택하지 않은 안

SSM 로드 로직이 세 곳(core provision-runtime.sh 4절, extractor·renderer 각자의 provision-observability.sh)에 중복이라, 이를 infra 공용 블록 하나로 통합하는 안을 먼저 만들었다(TeamPiKi/infra#46). 그러나 각 repo 의 스크립트가 이미 잘 동작하고 공용 블록을 fetch 해 쓰는 구조라 SSOT 도 어느 정도 지켜지고 있었다. 잘 도는 코드 세 벌을 건드리는 비용이 이득보다 커 폐기하고, 실제 결함(배포가 호출하지 않음)만 최소 변경으로 고쳤다. 중복 정리는 필요해질 때 별건으로 둔다.

Result

• 이후 infra 의 Alloy config 변경은 이 박스의 다음 배포에 자동 반영된다.
• 이 PR 머지 후 첫 배포에서 node_scrape_collector_success 시리즈 수가 41 → 12 로 떨어지는지, veth·/snap 시계열이 사라지는지로 검증할 수 있다.
• piki-db 박스는 앱 배포 자체가 없어 이 방식이 닿지 않는다. 별도로 다룬다.

연관 이슈

• close 배포가 Alloy 프로비저닝을 포함하도록 - config 변경이 박스에 반영되지 않던 문제 #38